Understanding Jamstack Security
Over the past few years, Jamstack (previously stylized as JAMStack) has emerged as a new architectural paradigm for delivering websites and web-based applications with the promise of improved performance, scalability, and security over the traditional server-driven approach to web development.
In the server-driven model, even the simplest website requires a web server such as Apache or Nginx to deliver its content, a database such as MYSQL to store and retrieve its data, and often an application layer or content management system (CMS) to create and manage that content.
By contrast, the simplest Jamstack site consists only of static files delivered directly to a user’s browser.
What is Jamstack?
The JAM in Jamstack stands for JavaScript, APIs, and markup—the three critical layers in the Jamstack architecture.
The markup layer replaces a traditional web application’s CMS and database-stored content with a static site generator (SSG). SSGs are tools that combine Markdown files with templates to output static HTML files through an automated build process. These files can then be served to a user’s browser using a content delivery network (CDN) provided by a Jamstack hosting service, such as Netlify or Vercel. Some SSGs also incorporate “headless” CMS systems, which allow non-technical users to create and manage content using a web UI decoupled from the deployed static files it builds.
Many free and open-source SSGs are available and written in various programming languages, each with an ecosystem of plugins, extensions, and customization capabilities for web developers to use in their projects.
The JavaScript layer of a Jamstack site facilitates interactivity and improved user experience through the JavaScript programming language, much like it does for the front end of a traditional web app. JavaScript’s Fetch API and the Ajax capabilities of various front-end frameworks also provide a means for interacting with third-party APIs, custom microservices, and serverless functions. Together, these make up the API layer of the Jamstack architecture and bring fully dynamic capabilities to Jamstack sites.
Jamstack security: things to consider
The promise of improved security for Jamstack sites is primarily due to the reduced attack surface compared to traditional web apps. However, although eliminating the web server and database layers drastically lowers the opportunity for exploitable vulnerabilities, there are still some significant security considerations to bear in mind with Jamstack sites, especially concerning the API layer of their architecture.
Jamstack provides security benefits over a traditional website architecture, including those listed below.
Increased security through decoupled APIs
Compared with a traditional, monolithic, server-driven web application architecture, there are some distinct security advantages to using the API layer of a Jamstack site.
Jamstack APIs generally consist of various third-party services for managing standard web application features, such as user authentication, payment processing, and e-commerce capabilities. They may also include custom microservices or serverless functions for providing dynamic user-based content and features.
Because Jamstack APIs are decoupled both from the SSG-generated static files comprising a Jamstack site’s front end and each other, security issues within those APIs are isolated and contained. This isolation poses less of a threat to the site and its underlying infrastructure.
In the same way that the decoupled microservice architecture’s components can scale independently, you can identify security vulnerabilities within the various API components in a Jamstack architecture and mitigate them independently without bringing down the entire system.
A reduced attack surface means safer sites
The most significant security improvement that a Jamstack site offers over a traditional web application is the reduced attack surface area that comes from a deployment strategy consisting only of delivering pre-rendered static files to the user’s browser. These pre-rendered pages load almost instantly, requiring only a single call to a globally distributed content delivery network (CDN) that provides caching and delivers content through the edge network that is closest to the user’s physical location.
You can compare this to the work required to load a single page for a traditional CMS website. A traditional site may begin by loading static assets through a CDN, followed by a call to a web server that may live on a shared hosting machine or a public cloud environment behind a load balancer. The site then makes one or more calls to a database that may live on a separate server or multiple servers. Finally, it’s delivered back to the user’s browser using a server-side programming language, such as PHP or Python, and the many underlying third-party software dependencies, packages, libraries, and frameworks used to build web applications in that language.
In a traditional web application architecture, every stage of that request and response cycle and every piece of software running to facilitate it represents a potential attack vector for a malicious actor. And the most popular open-source CMS tools, such as WordPress and Drupal, are some of the biggest targets of all, necessitating diligent security updates alongside the regular auditing, monitoring, and maintenance required by every system component.
As previously mentioned, the decoupled nature of the Jamstack API layer isolates and contains security threats to each API without threatening the system as a whole—like vulnerabilities in third-party software dependencies often do in a monolithic web application architecture. However, the APIs that a Jamstack site interacts with could pose a genuine security threat to your users if they have vulnerabilities or are otherwise susceptible to compromise.
Fortunately, there are some practical steps and approaches that you can take to mitigate that threat and keep your Jamstack sites secure.
Use a zero trust model
Jamstack sites, which consist of only pre-rendered static pages, provide a much higher level of security than a traditional dynamically generated web app. Still, a purely static site isn’t very interesting or user-friendly.
What are the implications for security when you want to add dynamic content to a Jamstack site using third-party or your server-hosted APIs?
Although the use of third-party APIs is often touted as a security advantage for Jamstack sites, in that the largest and most established API providers employ their teams of security engineers to monitor and maintain their services, it’s still best to operate from a zero trust security model when consuming external services in your application. This is especially important when providing user data to those services for authentication, authorization, and customized user experience. Zero trust means not trusting the security of any external connections from your system or your users’ identity until your system authenticates and authorizes them to interact with APIs with only the minimum necessary privileges.
Most APIs also require some form of token or key-based authentication, which can pose a security challenge for Jamstack sites where the entirety of the code base is available to the client and publicly accessible using a web browser’s developer tools.
A common strategy for protecting these authentication-related secrets in a Jamstack site is to use a serverless function as a wrapper for containing both the secret itself, generally stored as an environment variable, and any additional logic to limit the parameters and protect against API abuse on your site. Although the serverless function is called from your front-end code in the same way a direct API call is made, any sensitive credentials needed for API authentication can be safely stored in the serverless environments provided through cloud services, such as Google Cloud Functions and AWS Lambda.
An additional and vital layer of security protection that you should include in all Jamstack sites is the use of HTTPS for your own site and any external APIs that it interacts with.
Most Jamstack hosting providers enable SSL certification out of the box. Still, if you’re hosting your own site or using a shared hosting service for your deployment, it’s your responsibility to ensure that end-to-end encryption is in place. This ensures that your users’ sensitive authentication data isn’t exposed through HTTP headers or request query parameters. And regardless of your own site’s protection, it’s crucial to verify that all of your site’s external APIs follow this and other critical API security measures through TLS encryption, token-based authentication, rate limits, throttling, and API gateways.
Conclusion
Jamstack offers an exciting new architectural approach to web development that provides many benefits over traditional server-driven web applications, including increased performance, scalability, and security. However, along with the security improvements that come with a reduced attack surface area in Jamstack sites, there are additional considerations that you must make and measures that you must take to protect the security and privacy of your users—especially concerning the use of external APIs for delivering dynamic content.
This article highlighted several strategies for keeping your Jamstack site secure, including adopting a zero trust approach to external API use, leveraging serverless functions for protecting authentication secrets, limiting API usage, and ensuring HTTPS encryption is in place across your project and its external services.
It’s essential to stay up to date with the latest security measurements when working in such a rapidly developing space as Jamstack. Doing so will help you take advantage of the many improvements this architectural pattern offers over traditional web development while ensuring that you’re protecting your users’ interests and privacy.
